1. A file is sent as payload in a single JMS message where the payload is simply sent directly to the FTP server as a single file.
2. A file is sent as payload in a number of JMS messages within a given period of time where the message payloads are concatenated together in a common file when this time period has elapsed.
3. A file is sent as payload in a number of JMS messages delimited by an ”end of file” flag where the message payloads are concatenated together before sending to the FTP server when this flag appears.

• MessagePurpose and
• ResourceType
• SequenceNumber, EndofData and BuildInterval

• DestinationPath and the
• DestinationName

1. DestinationPath and DestinationName are optional JMS header properties and can be provided independently, e.g.
   JMS-Header property values: DestinationPath=not set, DestinationName=VERKASS/ITEMRSF.TXT and
   Configured default settings in XPDinteg.xml: DestinationPath=C:/POS_DAT, default DestinationName=ITEMR.TXT
   become the destination file of C:\POS_DAT\VERKASS\ITEMRSF.TXT
   
   
2. DestinationName property values can be created dynamically by using operands to create the DestinationName:
   
   Table 13: Operands for dynamic file name creation

Operand	Description	Example
<TIMEHHMMSS>	creates a current time stamp as String in the format HHMMSS (from the original HH:MM:SS, but w/o delimiters)	DestinationPath=C:/POS_DAT; DestinationName =VERKASS/ITEMR_<TIMEHHMMSS>.TXT creates C:\\POS_DAT\VERKASS\ITEMR_140733.TXT
<DATEDDMMYYYY>	current date stamp String in German format DDMMYYYY (from the original DD.MM.YYYY, but w/o delimiters)	DestinationPath=C:/POS_DAT; DestinationName =VERKASS/ITEMR_<DATEDDMMYYYY>.TXT creates C:\\POS_DAT\VERKASS\ITEMR_03122007.TXT
<DATEYYYYDDMM>	current date stamp String in en_US format YYYYDDMM (from the original YYYY-DD-MM., but w/o delimiters)	(equivalent to <DATEDDMMYYYY>)
<TRANSID_8>	last 8-digits of the TransactionId (EventId) from the JMS custom head	TransactionId=99912345678 and DestinationPath=C:/POS_DAT; DestinationName =VERKASS/<TRANSID_8>.TIT create target resource C:\\POS_DAT\VERKASS\12345678.TIT If the TransactionId has less then 8 characters, the DestinationName will be created with leading zeros (e.g. TransactionId=1234 would lead to DestinationName=00001234.TIT) Note: It is recommended to confirm different file types in different confirmation directories to avoid overwriting files with same (truncated) TxId, e.g. DestinationName=VERKASS/TIT/<TRANSID_8>.TIT
<TRANSID>	all digits of the TransactionId (EventId) from the JMS header	TransactionId=99912345678 and DestinationPath=C:/POS_DAT; DestinationName =VERKASS/ITEMR_<DATEDDMMYYYY>-<TRANSID>.TXT creates target resource C:\\POS_DAT\VERKASS\ITEMR_03122007-99912345678.TXT

For example, the 4690 PoS Controller requires a defined file footer line in order to process Price Update Files. This can be addressed by creating File Preprocessing Activities which are processed before the created target file is transferred from the Store Server to the 4690 Controller.

The BuildPriceUpdateFileFooterActivity in the buc100_PutPriceUpdate.flow addresses an example retail requirement for the Price Update File footer (see <XPDINTEG_HOME>/flowdefs). The following file footer generation algorithm was implemented as reference:

With the variables $1-$7 representing the following values, the footer line will be built using the algorithm in Listing 23:

• $1- Date in YYMMDD format
• $2- Time in HHMM format
• $3- File Name (this will consume at least 12 characters, if the filename has only 5 characters, 7 white spaces must be added after it)
• $4- Line Count before applying the footer
• $5- Word Count before applying the footer
• $6- Byte Count before applying the footer
• $7- Byte by Byte algorithms (always set to 5 zeros)
• $8- Byte Count of first line (This is considered as the first line in the message payload which is interpreted as file. It is NOT the first line of the destination file if the destination file already exists!).

Footer line = %6s %4s ENDE %12s %s %s %s %s",$1,$2,$3,$4,$5,$6,$7,$8

Table 14: Example for retail price update file footer

• The TransportType defines whether a local file system directory, a remote FTP or SSH directory must be accessed.
• The DestinationPath property contains the directory of which the file listing is requested.
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the response message can be created appropriately.

• com/ibm/integrator/flowtriggerevent/BrowseDirectory/FTP/JmsAdapter or
• com/ibm/integrator/flowtriggerevent/BrowseDirectory/LocalFileSystem/JmsAdapter
• com/ibm/integrator/flowtriggerevent/BrowseDirectory/SSH/JmsAdapter

• Flow file name for FTP directory: Default_BrowseFtpDir.flow or
• Flow file name for local file system directory: Default_BrowseLocalFileSystemDir.flow
• Flow file name for local file system directory: Default_BrowseSshDir.flow

• BrowseLocalFileSystemDirectoryActivity or
• BrowseFtpDirectoryActivity or
• BrowseSshDirectoryActivity

The message body (payload) contains an XML structure with the names of the files in the directory of interest.

Listing 24 : XML structure for Browse Directory reply message payload

<?xml version="1.0" encoding="utf-8" ?>

<listing type=”listingtype” targetName=”target”>

	<listing-item type=”itemtype” name=”name”/>

</listing>

• listingtype indicates the nature of the resource queried, e.g. ”FTP” or ”LocalFileSystem”.
• target indicates the target location queried i.e. a directory name.
• itemtype indicates an individual item type in the list, e.g. ”File” or ”Directory”.
• name indicates the name for the item in question, i.e. the file name.

Table 17: Drain Queue message definition

• The DestinationName property contains the jndiDestinationKey value (queue name) of the local queue of which the listing is requested.
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the log messages can be created appropriately.

Table 18: Browse Queue message definition

• The DestinationName property contains the jndiDestinationKey value (queue name) of the local queue of which the listing is requested.
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the response message can be created appropriately.

<?xml version="1.0" encoding="utf-8" ?>

<listing type=”listingtype” targetName=”target”>

	<listing-item type=”itemtype” name=”name”/>

</listing>

• listingtype indicates the nature of the resource queried, here “message destination” .
• target indicates the target location queried i.e. jndi name of the Lotus Expeditor micro broker queue
• itemtype indicates the user defined headers of the message
• name indicates the value of the above headers in the message.

Table 20: Execute Script message definition

• The DestinationPath and -Name properties contain the target path in the local file system where the script file in the payload is detached to and is then executed. If no payload is provided and a file with the matching DestinationPath/-Name already exists, this will be executed instead.
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the log message can be created appropriately.

dir

ping 10.10.10.10

mkdir testdir

Table 21: Platform Restart message definition

• The ResourceCmd specifies the executed operation:
  ResourceCmd=Command:{restart|stop};Param:console,reset
  The Command specifies whether to restart or stop the Expeditor integrator runtime. The Param options further define whether:
  console – runtime runs in an open OSGi Console (recommended)
  reset –Expeditor integrator should be re-set before restarting (Careful: re-creates all local messaging components and deletes existing messages in queues!)
  
  
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the log message can be created appropriately.

Table 22: ConfigUpdate message definition

• The ResourceCmd specifies the possible update modes:
• Either a complete configuration file is transferred. Then the DestinationPath/-Name are also required.
• or a list of parameters is sent in the message payload.
  
  
• The DestinationPath and -Name properties contain the target path and name of the local file system to which the configuration file in the message payload is detached and from where the changes are applied
  (default would be <XPDINTEG_HOME>/config/new/XPDinteg.xml or <XPDINTEG_HOME>/config/XPDintegRoles.xml).
  
  
• The TransferConfirmationMode property can only be used for updating the User Admin configuration:
• NONE - received update file is stored in under the default location <XPDINTEG_HOME>/config. Important: The name of the transferred file is maintained!
• DELETE – only the User Admin store configuration is updated, no local copy of XPDintegRoles.xml is is kept (recommended behaviour).
• WriteOther - received update file is stored under the name and location specified under updatesFileLocation
  
  
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the log message can be created appropriately.
  
  
• The Command specifies whether to restart or stop the Expeditor integrator runtime. The Param options further define whether:
  console – runtime runs in an open OSGi Console (recommended)
  reset –Expeditor integrator should be re-set before restarting (Careful: re-creates all local messaging components and deletes existing messages in queues!)

1. Sending a complete configuration file in the message payload (XPDinteg.xml):
• MessagePurpose=ConfigUpdate
• ResourceCmd=FILE;[Command:{restart | stop};Param:console,reset]
2. Sending a list of changed properties in the message only (for XPDinteg.xml).
• MessagePurpose=ConfigUpdate
• ResourceCmd=ParamList;[Command:{restart | stop};Param:console,reset]
  The message payload contains a list of selected properties of the XPDintegConfig.xml file. These properties are used to set the specific attributes of the integrator bundles using this flow. For example, the message body changing the Custom Log Service into Maintenance Mode would look like this:
  
  Listing 27: ConfigUpdate message payload for updating the Maintenance Mode property
  

  <?xml version="1.0" encoding="utf-8"?>
  

  <configurations>
  

      <configuration pid="com.ibm.rcp.integrator.customeventservice">
  

  <properties>
  

  	    <property name="MaintenanceMode" value="ON"/>
  

  </properties>
  

      </configuration>
  

  </configurations>

  
  
  
3. Sending a complete User Admin store configuration file in the message payload (XPDintegRoles.xml):
• MessagePurpose=ConfigUpdate
• ResourceCmd=UserConfigFILE;[Command:{restart | stop};Param:console,reset]
  
  
4. Sending a list of changed User Admin store configuration properties in the message only (for XPDintegRoles.xml).
• MessagePurpose=ConfigUpdate
• ResourceCmd=UserConfigParamList;[Command:{restart | stop};Param:console,reset]
  The message payload contains a list of selected properties of the XPDintegRoles.xml file.

• MessageReadActivity – Reads the Message from the CtrlQ.
• MessageToFileActivity – Converts the input message to a File. In memory representation of XPDinteg.xml file.
• FileWriteToFileSystemActivity – Writes the in memory representation of XPDinteg.xml file into <XPDINTEG_HOME>/config directory.
• TransformAndValidateActivity – Verfies the XPDinteg.xml file structure and transforms it into the XPDintegConfig.xml file and stores it the in memory.
• FileWriteToFileSystemActivity – Writes the in memory XPDintegConfig.xml file into <XPDINTEG_HOME>/config/system folder.
• ConfigStoreUpdateActivity – Transactional update of the OSGi configuration with the XPDintegConfig.xml file contents.
• PlatformRestartActivity – Restarts the platform based on the ResoruceCmd Attributes.

• MessageReadActivity – Reads the Message from the CtrlQ.
• RertriveAndUpdateConfigurationStoreActivity- Gets the configuration store using OSGi Configuration Admin and updates the information contained in the message payload. Creates an in memory representation XPDinegConfig.xml file.
• FileWriteToFileSystemActivity – Writes the in memory representation of XPDintegConfig.xml file into <XPDINTEG_HOME>/config/system directory.
• ConfigStoreUpdateActivity – Transactional update of the OSGi configuration with the XPDintegConfig.xml file contents.
• PlatformRestartActivity – Restarts the platform based on the ResoruceCmd Attributes.

• The ResourceCmd specifies the executed operation:
  ResourceCmd={ON | OFF}; [Command:{restart | stop};Param:console,reset]
  If the ResourceCmd contains ON then all the bundles maintenance mode property is changed to <maintenance mode="ON"> and if the ResourceCmd contains OFF, then it is changed to <maintenance mode="OFF">.
  The Command specifies whether to restart or stop the Expeditor integrator runtime. The Param options further define whether:
  console – runtime runs in an open OSGi Console (recommended)
  reset –Expeditor integrator should be re-set before restarting (Careful: re-creates all local messaging components and deletes existing messages in queues!)
  
• MessageId, TransactionId, LocationId and MessageSrcId must be provided so that the log message can be created appropriately.

• MessageReadActivity – Reads the Maintenance message from the CtrlQ
• RetrieveAndUpdateConfigurationStoreActivity – Gets the all the latest configuration of all the bundles from the Configuration Store, applies the latest <maintenance mode="…"> setting to all the bundles and generates the new XML File (XPDintegConfig.xml) with latest changes
• FileWriteToFileSystemActivity – Writes the above generated file to config/system folder
• ConfigStoreUpdateActivity – Updates the OSGi Config Admin Service’s Configuration Store with the latest XML File in a transactional manner.
• PlatformRestartActivity – If the platform commands are given in the ResourceCmd attribute then this will restart the platform using the XPDintegSvc feature